Many organisations use computer systems (hereafter referred to as “Information Systems”) to record, process and retrieve information. Examples of the kinds of information stored in information systems could include accounts receivable, accounts payable, stock levels, and the like. There are two basic types of information systems available to these organisations. These types can be thought of as “packaged” and “customised”.
Packaged types refers to information systems (software) that can be bought, set-up and used immediately. Packaged types work in a manner that is general enough that they can be used by a wide range of organisations without being customised to suit specific organisational requirements.
Customised types refers to information systems (software) that are designed, developed and maintained specifically for an organisation, industry or application, generally to fulfil specific and/or unique requirements within that organisation, industry or application.
For many organisations, industries or applications, custom designed software works or performs better than packaged software. Packaged software is designed to be general, to allow it to be used successfully in a range of organisations, industries or applications. To achieve this, packaged software has to be, so to speak, “A jack of all trades, a master of none”. Whilst packaged software will perform many of the fictions that are required, it will usually not perform all, and it will not perform some functions in the best way for the particular use that the packaged software is put.
Organisations, industries or applications which use packaged software often expend time and effort preparing information to be entered into the packaged software (or packaged information system), and manipulating information output by the packaged software, so that the packaged software may be used effectively. Even with this extra ongoing manual effort, some functions may not be managed by the information system at all. Packaged software is presently almost always faster and cheaper to implement than customised software (or customised information systems), which is the primary reason for the existence of packaged software.
Custom designed software (or custom designed information systems) is specifically designed for an industry or an organisation, so the extra manual work required by packaged software is typically not required with a customised information system. A customised information system will generally be developed to do whatever the industry or organization wants, and contain all functionality required, with very little, if any, manual work required in preparing information to be input, or manipulating information that has been output from the customised software to make it useful.
However, customised information systems generally take a relatively long time to implement and maintain, and require highly skilled and specialised personnel to implement and maintain the customised information systems, and therefore are often very expensive and time consuming to implement and maintain.
The extra time and cost to implement a customised information system is often justified by the decreased manual work required by a customised information system, when compared to a packaged information system. For some industries or organisations, there may be no packaged system suitable for them to use, in which case customised systems are the only option.
Although customised information systems can fit an industry or organisation's requirements exactly, because of the time taken to develop and maintain a customised information system, customised information systems usually do not fit what is required today—they generally fit what was required a few months or a few years ago. By the time the customised information system has been fully implemented or modified to fit the current needs of an industry or organisation, those needs are often no longer the current needs—the requirements have changed.
For this reason, although customised information systems will fit an industry or an organisation better than packaged information systems, they do not fit perfectly, and are usually expensive. This time delay in developing a customised information system, and the high expense of customised information systems, means that many organisations simply cannot afford a customised information system, and thus use a packaged information system, with the inherent disadvantages involved in using a packaged information system, or do not use a computerised information system at all.
Presently, when developing a customised information system, there is a standard method that is followed. The various steps within the method may vary, but generally they include the following steps:                1. Analysis (Work out what the information system needs to do)        2. Design (Work out how the information system should do it)        3. Coding (Make the information system do it)        4. Testing (Test that the results of the Coding step fit the results of the Design step and the results of the Analysis step, and that the industry or organisation for which the information system is being developed is satisfied that the information system will fulfil requirements)        5. Implementation (Render the information system up and running and able to be used by the industry or organisation, including loading any data required)        
Most of these steps require not only intensive work, but also require thorough documentation of the results of that work. There is a danger that the analysis results of the first step will be misunderstood, displaced or corrupted when designing the information system, or that the design will be misunderstood, displaced or corrupted when coding or testing the information system. Thorough documentation is required to prevent these mistakes from occurring. Therefore, the presently known method not only requires the time taken to carry out each step of the method, but also requires time to be taken simply to ensure that the results of one step are carried successfully through to the next step.
For larger or complex customised information systems, the information system will often be broken into components, and then into sub-components, and the five step method will be carried out for each subcomponent. The results of the method for the previous component or sub-component are then built on when developing the next component or subcomponent. This is useful to ensure that the information system being developed or maintained conforms to requirements, but consumes time and increases the cost of the information system.
An information system consists of one or more databases, which in turn consist of a number of classes (in some systems called tables or files) which are related to each other. Each class contains instances which share the same possible list of attributes, but may contain different values against each of those attributes. Instances within classes can be related to instances within other classes. Classes within presently known systems tend to be related in a hierarchical manner. That is, some classes are clearly subservient to some other classes. This structure is illustrated in FIG. 1 (prior art).
The relationships between these classes are defined (duplicated or replicated) in every program that needs to derive data that is related to other data. That is, if a program needs to find all instances in class A (10) that are related to a given instance(s) in class B (12), that program must understand how the data in class A (10) is related to the data in class B (12). This makes programs longer and more difficult to write and to maintain, and means that it takes a relatively long time to implement and to maintain the programs, and requires highly skilled and specialised personnel to do so. This also means that programs must be changed when the relationships between classes changes. Programs that require this understanding include programs that validate data, that derive data, and that are used for searching or “drilling”. As illustrated in FIG. 1, class A (10) is also directly related to class C (14). Class D (16), class E (18), class F (20) and class G (22) are each related to class A (10) via class B (12).
For example, if a program needed to retrieve the values of the attribute “Amount” from the class “Invoice”, it could look like the following:    Variable=0    SELECT Invoice Class WHERE CustomerAttribute=“00001”    FOR Each InvoiceInstance Selected            GET Each InvoiceInstance        Variable+=InvoiceInstance.Amount        
Most programs require recursion or looping—that is, repeating a series of instructions a number of times. This makes writing and maintaining these programs more difficult, more time consuming, more costly, and requires a high level of knowledge and skill. Most programs also require branching—the ability to choose which series of instructions within the program should be followed.
For example, if a program needed to retrieve the values of either the attribute “Amount” or the attribute “DiscountAmount”, depending on whether the customer received a discount or not, from the class “Invoice”, it could look like the following:    Variable=0    GET CustomerInstance FROM Customer Class FOR Customer “00001”    SELECT Invoice Class WHERE Customer Attribute=“00001”    FOR Each InvoiceInstance Selected            GET Each InvoiceInstance        IF CustomerInstance.DiscountFlag=‘Y’ THEN                    Variable+=InvoiceInstance.DiscountAmount                        ELSE                    Variable+=InvoiceInstance.Amount                        
Programs are written to perform complicated validation, and to perform derivation Validation refers to ensuring that the data is correct. Derivation refers to calculating new data from other data. If programs are poorly written, the data will not be validated correctly, and derived data may not be calculated correctly. Programs should also be written to take into account that an update in one class may require updates in other classes, which may require updates in other classes, etc. Any failure for the programs to take this into account can result in the data that is stored within the system being inaccurate.
For example, if a program needed to validate that a particular customer was entitled to purchase a given product, it could look like the following. This example could be of a wholesaler which sells any quantity of any products to a retailer, but only sells a limited range of products to private individuals:    GET CustomerInstance FROM Customer Class FOR Customer “00001”    IF CustomerInstance.Type=‘Private’ THEN            GET ProductInstance FROM Product Class FOR SaleInstance.Product        IF ProductInstance.CustomerType NE ‘Private’ THEN                    Error                        
As a further example, if a program needed to update a customer's balance whenever a new sale occurred, and whenever a payment was received, it could look like the following:    GET CustomerInstance FROM Customer Class FOR    SaleInstance.CustomerNumber    CustomerInstance.Balance+=SaleInstanceAmount    PUT CustomerInstance ON Customer Class FOR SaleInstance.CustomerNumber    GET CustomerInstance FROM Customer Class FOR    ReceivedInstance.CustomerNumber    CustomerInstance.Balance−=ReceivedInstanceAmount    PUT CustomerInstance ON Customer Class FOR    Received Instance.CustomerNumber
This identifies a need for an unproved method of and new computer software for designing, developing and/or maintaining customised information systems which overcomes or at least ameliorates the problems inherent in the prior art as discussed previously.
This also identifies a need to provide a means for classes within an information system not to be required to be solely related in a hierarchical manner. That is, although classes can be clearly subservient to some other classes, classes do not necessarily have to be related in a hierarchical manner as in the prior art. There is a need for classes to be able to be related in a more flexible manner.
Definitions
Access to an information system is provided by terminals which are capable of requesting and receiving information from local or remote information sources. A terminal may be any type of computer or computerised device, a personal computer (PC), a mobile or cellular phone, a mobile data terminal, a portable computer, a personal digital assistant (PDA), a pager, a thin client, or any other similar type of electronic device. The capability of the terminal to request and/or receive information can be provided by an application program which may or may not be part of the information system, hardware or other such entity. A terminal may be provided with associated devices, for example an information storage device such as a hard disk drive.
An information source may be a server or any other type of terminal (for example, a PC computer) coupled to an information storage device (for example, a hard disk drive). The exchange of information (i.e., the request and/or receipt of information) between the terminal and the information source, or other terminal(s), is facilitated by a communication channel. The communication channel may be physically realised via a metallic cable (for example, a telephone line), semiconducting cable, an electromagnetic signal (for example, a radio frequency (RF) signal), an optical fibre cable, a microwave link, a satellite link or any other such medium or combination thereof connected to a network infrastructure.
The terms ‘data’ and ‘information’ are used within this document to assist in describing the scope of the present invention. For the purposes of describing and defining the present invention, the terms are taken to be interpreted as:
Data—The separate components which make up information. Individually, the components are not generally useful; an industry or organisation cannot use the data to determine the best action to take. As an analogy, data could be thought of as the bricks, mortar, wood and nails of a house. Separately, they are of no use; but when they are put together to form a house, they perform a useful purpose. An example of data might be a customer number, an amount of money, and a date. There is generally no useful action that can be taken with these the separate pieces of data.
Information—Data that has been put together in such a way as to be useful. To continue the analogy, a house can be thought of as bricks, mortar, wood and nails that have been put together in such a way as to be useful. An example of information might be a customer number, with a related amount of money due, with a related date due that is three months in the past. This is the same data used in the previous definition of data, but because the data has been put together in the right way, an organisation can now take appropriate action based on selected criteria. The appropriate action could be, for example, to refer a debt to a debt collector, or just call a customer and speak with them about a debt.
Generic object oriented terminology is used in this specification, but not exclusively. The following definitions are used to clarify terms in this specification.                Instance—Could also be called a record within a file, or a row within a table. An instance is a see, distinct item, stored among items of a similar type, within the system. For example, all orders are likely to be stored within the same class. Each separate order is an instance within that class.        Class—Could also be called a file or a table. All information of a particular type is stored in a particular class. For example, all orders are likely to be stored within one class, and all customer information is likely to be stored within another class.        Attribute—Could also be called fields on a file, or columns on a table. Every separate piece of data is stored as an attribute. For example, an order class is likely to contain the following attributes: Order number, customer number, date, amount, delivery instructions, and so on. A customer class is likely to contain the following attributes: Customer number, name, address, phone number, fax number, credit limit, and so on.        Relationship Category—Refers to how data can be related to other data. Many different relationship types can fit within the one relationship category. Basically, data can be related to other data by being Not Equal (NE), Greater Than (GT), Greater than or Equal (GE), Equal (EQ), Less than or Equal (LE) or Less Than (LT) the other data. Relationship category is one of the two phrases used within this specification to describe the relationships between data. Relationship Type is the other phrase.        Relationship Type—Further defines, or narrows down, how data can be related to other data. Every relationship type fits within a relationship category. There are two basic reasons for there being multiple relationship types within one relationship category. 1. The first is that it is possible to define that a piece of data is related to one specific other piece of data, by defining that it is the first or last piece of other data to which it is related. For example, the relationship type <==(Less than or Equal Equal) belongs to relationship category LE, but refers to the one piece of other data that is less than or equal to the data, and is most equal. If there are multiple pieces of other data, the piece most equal to the data will be chosen. 2. Relationship types can be written in multiple ways, eg <# is equivalent to < and #<, yet they all belong to the same relationship category.        Program—Any series of instructions telling a computer what to do, and what order to do it in. Generally called a Method in Object Oriented terminology. Could also be called an applet, subroutine, module, script, batch, or function. There are other possible names also, not included here.        